Communication network and method for processing pre-chargeback disputes

ABSTRACT

A pre-chargeback computer network for processing pre-chargeback dispute messages includes a dispute analyzer (DA) computing device. The DA computing device is configured to receive a dispute message identifying a disputed transaction from an issuer portal over a first communication link, the dispute message including transaction data associated with the disputed transaction and dispute data. The DA computing device is further configured to analyze the transaction data and the dispute data, and route the dispute message over the pre-chargeback network or a separate chargeback network based on the analysis.

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional PatentApplication No. 62/335,369, filed on May 12, 2016, the contents of whichare hereby incorporated herein by reference for all purposes.

BACKGROUND

The present application relates generally to communication networks and,more particularly, to a network-based system and method for uniquelylinking parties via a communication network to resolve pre-chargebackdisputes.

When a cardholder uses a payment card (e.g., a credit card or a debitcard) to initiate a transaction to purchase goods or services from amerchant, an acquiring bank (i.e., the merchant's bank) will typicallyreimburse the merchant for the transaction. The acquiring bank will thensettle those funds with an issuing bank of the account corresponding tothe payment card by presenting transaction data, associated with thetransaction, to a payment processor. In a process known as clearing,transaction data is communicated from the acquiring bank through thepayment processor to the issuing bank. After clearing, settlement of thefinal payment occurs via the payment processor. Settlement is a processused to exchange funds between the acquiring bank and the issuing bankfor the net value of a batch of all monetary transactions that havecleared for that processing day.

On occasion, the cardholder may be unsatisfied with the goods orservices provided by the merchant, may not recognize the purchase, maydetermine the purchase is fraudulent, or may otherwise dispute thetransaction. In these examples, the user may initiate a transactiondispute, known as a chargeback, with the issuing bank. The chargebackmay be used to return some or all of the funds associated with thedisputed transaction to the account corresponding to the payment card.Theses chargeback disputes are also processed over the payment network.Typically, the issuing bank immediately issues a credit to the accountfor the amount of the transaction. The issuing bank then sends achargeback request to an issuing bank processor, and the request iscollected with other requests and submitted in a batch to the paymentprocessor. The chargeback request is then sent to the acquiring bank oran acquirer processor. However, the merchant may dispute the chargebackwith the assistance of the acquiring bank. The issuing bank and theacquiring bank may then attempt to mediate the charge through anarbitration proceeding. Depending on the outcome, the cardholder, theissuing bank, the acquiring bank, or the merchant may be left with thecost of the transaction.

The chargeback process is complicated, time consuming, and/or costly toall participants involved. Each chargeback transmitted through thepayment processor and over the payment network consumes networkresources and bandwidth.

However, some transaction disputes could be resolved between thecardholder and the merchant without a chargeback request. Unfortunately,a system that allows cardholders to communicate directly with a merchantregarding questionable transactions does not exist. Rather, thecardholder is only given the option of submitting a chargeback.Accordingly, it is desirable to have a system that allows a cardholderto submit a dispute, the system including a communication networklinking a cardholder with a merchant to resolve at least some disputeswithout having to use payment processor resources.

BRIEF DESCRIPTION

In one aspect, a pre-chargeback computer network for processingpre-chargeback dispute messages is provided. The pre-chargeback computernetwork includes a dispute analyzer (DA) computing device incommunication with a memory, an issuer portal, and a first communicationlink connecting the issuer portal to the DA computing device. The DAcomputing device is configured to receive a dispute message identifyinga disputed transaction from the issuer portal over the firstcommunication link, the dispute message including transaction dataassociated with the disputed transaction and dispute data. The DAcomputing device is further configured to analyze the transaction dataand the dispute data, and route the dispute message over thepre-chargeback network or a separate chargeback network based on theanalysis.

In another aspect, a computer-implemented method for processingpre-chargeback dispute messages over a pre-chargeback network isprovided. The method is implemented using a dispute analyzer (DA)computing device. The method includes receiving, by the DA computingdevice, a dispute message identifying a disputed transaction from anissuer portal over a first communication link, the dispute messageincluding transaction data associated with the disputed transaction anddispute data. The method also includes analyzing, by the DA computingdevice, the transaction data and the dispute data, and routing, by theDA computing device, the dispute message over the pre-chargeback networkor a separate chargeback network based on the analysis.

In yet another aspect, a non-transitory computer readable medium thatincludes computer executable instructions for processing pre-chargebackdispute messages over a pre-chargeback network is provided. Whenexecuted by a dispute analyzer (DA) computing device including at leastone processor in communication with at least one memory device, thecomputer executable instructions cause the DA computing device toreceive a dispute message identifying a disputed transaction from anissuer portal over a first communication link, the dispute messageincluding transaction data associated with the disputed transaction anddispute data. The computer executable instructions further cause the DAcomputing device to analyze the transaction data and the dispute data,and route the dispute message over the pre-chargeback network or aseparate chargeback network based on the analysis.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1-6 show example embodiments of the methods and systems describedherein.

FIG. 1 is a schematic diagram illustrating an exemplary multi-partypayment network system for processing payment card transactions.

FIG. 2 is a schematic diagram illustrating an exemplary multi-partynetwork system for processing payment card chargebacks.

FIG. 3 is a schematic diagram illustrating an exemplary computer systemthat includes a dispute analyzer (DA) computing device for designatingtransaction disputes as either chargeback disputes or pre-chargebackdisputes.

FIG. 4 is a data flow diagram illustrating an example method of apre-chargeback dispute resolution using the DA computing device, asshown in FIG. 3.

FIG. 5 is a schematic diagram of an example server computing device thatmaybe used with the computer system shown in FIG. 3.

FIG. 6 is flowchart of an example process for designating a transactiondispute as either a chargeback dispute or pre-chargeback dispute.

DETAILED DESCRIPTION

Described herein is a transaction dispute communication system linkingcardholders with merchants for resolving transaction disputes betweensaid parties. This “pre-chargeback system” enables resolution oftransaction disputes before or without submitting the transactiondisputes over a payment network as chargebacks. Therefore, thepre-chargeback system reduces traffic processed by the payment networkby providing a network communication link between said parties foraddressing these pre-chargebacks.

The pre-chargeback system enables resolution of transaction disputesbetween cardholders, issuers (e.g., issuing banks), and merchants, toavoid submitting chargebacks to the payment network. The pre-chargebacksystem includes at least a transaction dispute analyzer (DA) computingdevice, an issuer portal, a merchant portal, and a pre-chargebacknetwork including one or more communication channels or links. The DAcomputing device includes at least one processor in communication with amemory. The DA computing device is in communication with the issuerportal and the merchant portal and is configured to exchange one or moremessages between these portals, or a cardholder and a merchant, tofacilitate resolving a transaction dispute. A “pre-chargeback,” as usedherein, is defined as a dispute or question raised by the cardholderwith respect to a payment transaction. For example, a cardholder mayidentify an incorrect transaction amount, or may not recognize themerchant based on the payment transaction data. Such a dispute may beresolved by the merchant without having to submit the dispute inquestion through the chargeback process. In some cases, if apre-chargeback cannot be resolved through the pre-chargeback system, thepre-chargeback may then be submitted as a chargeback through the paymentnetwork.

The issuer portal is communicatively coupled to the DA computing deviceover a first network connection. The merchant portal is communicativelycoupled to the DA computing device over a second network connection. Thefirst and/or second network connection may include, for example, a localarea network (LAN) or a wide area network (WAN), dial-in-connections,cable modems, and special high-speed Integrated Services Digital Network(ISDN) lines. In some embodiments, the issuer portal and/or the merchantportal may be communicatively coupled to a payment processor. In oneembodiment, the DA computing device is in communication with or is apart of the payment processor. In another embodiment, the DA computingdevice is integrated with the issuer server. In some embodiments, the DAcomputing device functions as a router and provides a number of networkinterfaces. Each network interface may be associated with IP addressinformation (e.g., interface IP address and subnet) to enable theexchange of data. Routers are well known to those of ordinary skill inthe art and will not be further described except as to how they relateto embodiments of the disclosure.

In one example embodiment, a cardholder, using an internet-enabled usercomputing device (such as a mobile phone, smartphone, personal digitalassistants (PDA), desktop computer, or laptop computer) accesses acontrolled-access issuer portal associated with an issuing bank. Theissuer portal may be a website/webpage, a series of websites/webpages, aweb application, or a mobile application connected to an issuer server.The cardholder accesses the issuer portal to view an online bankingaccount associated with a payment card issued by the issuing bank andassigned to the cardholder. The payment card is used to initiate apayment for goods or services to a merchant. The cardholder may berequired to enter information such as login information into the issuerportal to interact with the issuer portal and view the online bankingaccount. The online banking account may include a transaction historyassociated with the payment card.

The cardholder uses the issuer portal to review the transaction historyassociated with the payment card. The issuer portal further includes oneor more features enabling the cardholder to dispute a transaction listedin the transaction history. For example, the cardholder can select atransaction to dispute. This dispute will either be processed throughthe pre-chargeback network as a pre-chargeback or through the paymentnetwork as a chargeback. The issuer portal may provide one or morefeatures within a user interface that enable the cardholder to select atransaction to dispute, such as a button or checkbox. The issuer portalmay additionally provide one or more features that enable the cardholderto indicate a reason for the dispute, such as a drop-down menu, amultiple-choice list, and/or a text entry field. The cardholder may, forexample, dispute the transaction because the cardholder is unsatisfiedwith goods or services provided by the merchant, the cardholder does notrecognize a purchase, the cardholder believes that a transaction amountis wrong, and/or the cardholder determines a purchase is fraudulent.Information associated with the selected transaction for dispute,including the cardholder-provided data regarding the reason(s) for thedispute, is referred to herein as “cardholder dispute data”.

The issuer portal may further include one or more messaging sections toreceive and display messages to the cardholder. For example, themessages may be in the form of electronic messages (e.g., e-mails orinstant messages) from one or more merchants and/or the issuer. Thecardholder is able to view and respond to the messages within the one ormore messaging sections.

After selecting a transaction to dispute from the issuer portal andproviding the cardholder dispute data, the cardholder uses the issuerportal to submit the dispute (e.g., by selecting a “submit” option). Theissuer portal retrieves transaction data associated with the disputedtransaction and generates a dispute message including the transactiondata and the cardholder dispute data. The associated transaction dataincludes, but is not limited to, a primary account number (PAN)associated with a payment card used to initiate the transaction, accountprofile data for the PAN, a merchant identifier (ID), an acquiring bankidentifier, an issuing bank ID, an original transaction amount, atransaction date and time, a merchant location ID, a card product type,a merchant category code, an authorization code, and/or othertransaction identifiers that may be used to identify the merchant and/orthe disputed transaction. The issuer portal may generate a disputeidentifier associated with the dispute and include the dispute ID withinthe dispute message. The issuer portal may further generate a reasoncode associated with the cardholder provided reason for the dispute,wherein the reason code is a particularly formatted data elementconfigured to easily communicate the reason for the dispute themerchant. The dispute message is transmitted by the issuer server to theDA computing device.

The DA computing device receives the dispute message. In the exampleembodiment, the DA computing device is configured to analyze the disputemessage and determine whether to transmit the dispute message throughthe payment network (e.g., to the payment processor) for the normalchargeback process or through the pre-chargeback network for potentialresolution. In some embodiments, the issuer portal and/or a cardholderstatement indicate that a pre-chargeback is in pending status and underreview.

The DA computing device may use natural language processing, and/orstatistical methods, and/or other machine learning methods to analyzethe dispute data to determine where to route the dispute message. Forexample, in one embodiment, the DA computing device may identifyparticular data (“indicators”) that are historically associated withdisputed transactions that have been resolved by pre-chargeback networkcommunication between a merchant and a cardholder. For example,cardholders that dispute transactions because they don't recognize themerchant associated with the transaction may include the phrase “don'trecognize” in the cardholder dispute data. If such disputes are oftenresolved by pre-chargeback network communication between the merchantand the cardholder, the DA computing device may learn to associate thephrase “don't recognize” with a high probability of pre-chargebackresolution and route applicable dispute messages through thepre-chargeback network for potential resolution. These indicators may bestored in a database associated with the DA computing device. In someembodiments, the DA computing device also uses keywords or indicatorsfrom the dispute message to determine how to route the dispute message.

In another embodiment, the issuer portal enables the cardholder tochoose whether to submit the transaction dispute directly through thenormal chargeback process or to the merchant via the pre-chargebacksystem for transaction dispute resolution. In such an embodiment, theissuer imbeds an indicator of the cardholder submission selection intothe dispute message as part of the cardholder dispute data, and the DAcomputing device identifies the indicator of the cardholder selectionupon processing the cardholder dispute data embedded within the disputemessage. If the cardholder chooses to submit the dispute directlythrough the normal chargeback process, the DA computing device transmitsthe dispute message to the payment processor as a chargeback message. Inan alternative embodiment, the issuer portal is in direct communicationwith the payment processor and transmits the dispute message as achargeback message directly to the payment processor without using theDA computing device. Alternatively, if the cardholder chooses to submitthe dispute to the merchant as a pre-chargeback, the issuer portaltransmits the dispute message to the DA computing device. The DAcomputing device then transmits the dispute message to the merchantportal associated with the merchant identified in the dispute message asa pre-chargeback message. The merchant accesses the merchant portal toaccess and respond to the pre-chargeback message, as described below.

In still another embodiment, the issuer server itself determines whetherto enable the cardholder to communicate directly with the merchant usingthe pre-chargeback network. For example, the issuer portal may include apop-up browser enabling the cardholder to transmit the dispute messageto the DA computing device for pre-chargeback resolution.

Upon receiving a dispute message and determining the dispute message isto be routed through the pre-chargeback network as a pre-chargebackmessage, the DA computing device transmits the pre-chargeback message toa merchant server. In one embodiment, the DA computing device isconfigured to use the dispute message, particularly the associatedtransaction data, to determine the merchant associated with thepre-chargeback message. In some embodiments, each merchant has aseparate merchant portal. In such embodiments, the DA computing devicedetermines the particular merchant server that provides the merchantportal for the identified merchant. The DA computing device transmitsthe pre-chargeback message to that merchant server. In an alternativeembodiment, all merchants share a merchant portal but each merchant hasa separate messaging section to display, receive, and transmit messagecommunications. In such embodiments, the DA computing device transmitsthe pre-chargeback message to a central merchant server that provides amerchant portal.

The merchant portal displays the pre-chargeback message, including atleast some of the cardholder dispute data, enabling the merchant toreview new pre-chargebacks and updates to existing pre-chargebacks. Themerchant portal can be a website/webpage, a series of websites/webpages,a web application, or a mobile application. The merchant portal furtherincludes one or more messaging sections to display one or more receivedmessages (such as text message communications, electronic mail (i.e.,emails), and/or other information) relating to one or morepre-chargebacks. The merchant then reviews the pre-chargeback messagesand provides a pre-chargeback response message. The response mayinclude, for example, querying the cardholder for additional detailand/or providing store credit with the merchant to the cardholder.

In some embodiments, the merchant portal is part of and/or is hosted bythe DA computing device and accessible to merchants. In alternativeembodiments, a separate computing device (e.g., a merchant portal) hoststhe merchant portal(s).

The merchant can also respond to the cardholder by using the one or moremessaging sections to create and transmit a pre-chargeback responsemessage through the pre-chargeback network (e.g., the secondcommunication link) to the DA computing device. The DA computing deviceis configured to then transmit the pre-chargeback response message tothe issuer portal. In some embodiments, the cardholder is notified ofthe pre-chargeback response message. For example, a visual queue appearsin the issuer portal or on a cardholder statement. In some embodiments,the cardholder is notified of the pre-chargeback response message viatheir preferred method of contact provided by the cardholder to theissuer (e.g., mobile phone prompt/text message, email, telephone call,etc.).

The cardholder may use the issuer portal to respond to thepre-chargeback response message to continue the pre-chargebackresolution process. The cardholder may agree to a resolution proposed bythe merchant in the pre-chargeback response message. Alternatively, thecardholder and the merchant can continue to exchange messages using theabove-described process.

In some embodiments, the merchant may choose to respond to thepre-chargeback message by submitting the dispute to the payment networkfor processing through the normal chargeback process. For example, themerchant may receive the pre-chargeback message and decide that thepre-chargeback is more appropriate for the chargeback process. In oneembodiment, the merchant notifies the DA computing device to submit thepre-chargeback to the payment processor. In another embodiment, themerchant is in direct communication with the payment processor or indirect communication with the acquirer and can begin the chargebackprocess without the DA computing device.

The technical effects achieved by the systems and methods describedherein include providing a new communication network (a “pre-chargebacknetwork”) between consumers (e.g., cardholders and issuing banks) andmerchants for resolving transaction disputes between the parties priorto or without submitting the disputed transactions as chargebacksthrough the payment processor. The pre-chargeback system describedherein enables consumers and merchants to more easily resolve thesedisputes by enabling the parties to communicate directly, submitquestions, ask for more information, etc. The pre-chargeback systemfacilitates reducing the number of chargebacks submitted to the paymentprocessor, freeing up network resources and bandwidth for processingpayments and increasing a speed of the payment processor. In turn, thepayment network may experience more accurate data processing and lessnetwork traffic from chargebacks. In addition, reducing the number ofchargebacks may lead to reducing a number of issuer declines.

The methods and systems described herein may be implemented usingcomputer programming or engineering techniques including computersoftware, firmware, hardware or any combination or subset thereof,wherein the technical effect may be achieved by performing at least oneof the following steps: (a) receiving, at a DA (dispute analyzer)computing device, a dispute message from an issuer portal containingdispute data associated with a transaction dispute; (b) determiningwhether to designate the transaction dispute described in the disputemessage as either a pre-chargeback or a chargeback; (c) transmittingchargebacks to a payment processor; (d) transmitting pre-chargebacks toa merchant challenge portal; (e) receiving at a DA computing device, apre-chargeback response message from the merchant portal; and (e)transmitting the pre-chargeback response message to the issuer portal.

In one embodiment, a computer program is provided, and the program isembodied on a computer-readable medium. In an example embodiment, thesystem is executed on a single computer system, without requiring aconnection to a sever computer. In a further example embodiment, thesystem is being run in a Windows® environment (Windows is a registeredtrademark of Microsoft Corporation, Redmond, Wash.). In yet anotherembodiment, the system is run on a mainframe environment and a UNIX®server environment (UNIX is a registered trademark of AT&T located inNew York, N.Y.). The application is flexible and designed to run invarious different environments without compromising any majorfunctionality. In some embodiments, the system includes multiplecomponents distributed among a plurality of computing devices. One ormore components may be in the form of computer-executable instructionsembodied in a computer-readable medium. The systems and processes arenot limited to the specific embodiments described herein. In addition,components of each system and each process can be practicedindependently and separately from other components and processesdescribed herein. Each component and process can also be used incombination with other assembly packages and processes.

The following detailed description illustrates embodiments of thedisclosure by way of example and not by way of limitation. It iscontemplated that the disclosure has general application to providing apre-chargeback system to resolve transaction disputes betweencardholders and merchants, thus providing an alternative to thechargeback process.

As used herein, an element or step recited in the singular and precededwith the word “a” or “an” should be understood as not excluding pluralelements or steps, unless such exclusion is explicitly recited.Furthermore, references to “example embodiment” or “one embodiment” ofthe present disclosure are not intended to be interpreted as excludingthe existence of additional embodiments that also incorporate therecited features.

Financial transaction cards or payment cards can refer to credit cards,debit cards, and prepaid cards. These cards can all be used as a methodof payment for performing a transaction. As described herein, the term“financial transaction card” or “payment card” includes cards such ascredit cards, debit cards, and prepaid cards, but also includes anyother devices that may hold payment account information, such as mobilephones, personal digital assistants (PCAs), and key fobs.

FIG. 1 is a schematic diagram illustrating an exemplary multi-partypayment card processing system 100 for processing and disputingpayment-by-card transactions. The present system and method relates topayment card processing system 100, such as a credit card paymentnetwork using the Mastercard® payment processor 106. Mastercard® paymentprocessor 106 is a proprietary communications standard promulgated byMastercard International Incorporated® for the exchange of financialtransaction data between financial institutions that are registered withMastercard International Incorporated®. (Mastercard is a registeredtrademark of Mastercard International Incorporated located in Purchase,N.Y.).

In payment card processing system 100, a financial institution, such asan issuing bank 104, issues a payment card, such as a credit cardaccount or a debit card account, to a cardholder 102, who uses thepayment card to tender payment for a purchase from a merchant 110. Toaccept payment with the payment card, merchant 110 must normallyestablish an account with a financial institution that is part of thefinancial payment system. This financial institution is usually calledthe “merchant bank” or the “acquiring bank” or simply “acquirer”. When acardholder 102 tenders payment for a purchase with a payment card (alsoknown as a financial transaction card), merchant 110 requestsauthorization from merchant bank 108 for the amount of the purchase. Therequest may be performed over the telephone or via a website, but isoftentimes performed through the use of a point-of-sale terminal, whichreads the cardholder's account information from the magnetic stripe onthe payment card and communicates electronically with the transactionprocessing computers of merchant bank 108. Alternatively, merchant bank108 may authorize a third party to perform transaction processing on itsbehalf. In this case, the point-of-sale terminal will be configured tocommunicate with the third party. Such a third party is usually called a“merchant processor” or an “acquiring processor.”

Using payment processor 106, the computers of merchant bank 108 or themerchant processor will communicate with the computers of issuing bank104 to determine whether the cardholder's account is in good standingand whether the purchase is covered by the cardholder's available creditline or account balance. Based on these determinations, the request forauthorization will be declined or accepted. If the request is accepted,the transaction is given a bank network reference number, such as theBanknet Reference Number used by Mastercard International Incorporated®,an authorization code, and/or other transaction identifiers that may beused to identify the transaction.

During the authorization process of the payment card system, theclearing process is also taking place. During the clearing process,merchant bank 108 provides issuing bank 104 with information relating tothe sale. No money is exchanged during clearing. Clearing (also referredto as “first presentment”) involves the exchange of data required toidentify the cardholder's account 112 such as the account number,expiration date, billing address, amount of the sale, and/or othertransaction identifiers that may be used to identify the transaction.Along with this data, banks in the United States also include a banknetwork reference number, such as the Banknet Reference Number used byMastercard International Incorporated®, which identifies that specifictransaction. When the issuing bank 104 receives this data, it posts theamount of sale as a draw against the cardholder's 102 available creditand prepares to send payment to the merchant bank 108.

When a request for authorization is accepted, the available credit lineor available account balance of cardholder's account 112 is decreased.Normally, a charge is not posted immediately to a cardholder's account112 because bankcard associations, such as Mastercard InternationalIncorporated®, have promulgated rules that do not allow a merchant tocharge, or “capture,” a transaction until goods are shipped or servicesare delivered. When a merchant 110 ships or delivers the goods orservices, merchant 110 captures the transaction by, for example,appropriate data entry procedures on the point-of-sale terminal. If acardholder 102 cancels a transaction before it is captured, a “void” isgenerated. If a cardholder 102 returns goods after the transaction hasbeen captured, a “credit” is generated.

After a transaction is captured, the transaction is settled betweenmerchant 110, merchant bank 108, and issuing bank 104. Settlement refersto the transfer of financial data or funds between the merchant'saccount, merchant bank 108, and issuing bank 104 related to thetransaction. Usually, transactions are captured and accumulated into a“batch,” which is settled as a group.

FIG. 2 is a schematic diagram illustrating an exemplary multi-partynetwork system 200 for processing payment card chargebacks. In oneembodiment, system 200 is similar to or the same as system 100 as shownin FIG. 1. In some cases, cardholder 202 disputes a transaction that mayhave been carried out using payment card system 200. A transactiondispute may occur for technical reasons such as insufficient funds,clerical reasons such as duplicate billing and/or incorrect amountbilled, quality reasons such as when a cardholder claims to have neverreceived the goods as promised, and/or fraud reasons where a cardholderdid not authorize the purchase. A transaction dispute may become achargeback.

To initiate a chargeback, cardholder 202 may contact issuing bank 204 todispute a transaction. Issuing bank 204 submits a chargeback transactionto payment processor 206, which provides clearing and settlementservices to its registered users. Payment processor 206 may be the sameor similar to the payment processor 106 described in FIG. 1. Paymentprocessor 206 submits the chargeback to merchant bank 208. Merchant bank208 either resolves the dispute or forwards it to merchant 210. Merchant210 either accepts the chargeback or re-presents it back to merchantbank 208. If merchant 210 accepts the chargeback, merchant bank 208forwards the response back to payment processor 206. Payment processor206 then settles the chargeback with issuing bank 204. If merchant 210re-presents the chargeback, merchant bank 208 rejects the chargebackrequested by issuing bank 204. Merchant bank 208 may provide additionalproof or documentation that the transaction was valid. Based on thesecond presentment, issuing bank 204 either accepts it and takes nofurther action, or rejects the second presentment, which is a stagereferred to as arbitration chargeback. Once arbitration chargebackoccurs, neither issuing bank 204 nor merchant bank 208 may initiate anyadditional chargebacks or presentments. At this point, a case filing isautomatically generated with payment processor 206, which issues afinancial liability decision regarding the chargeback.

FIG. 3 is a schematic diagram illustrating an exemplary multi-partynetwork system 300 that includes a dispute analyzer (DA) computer device316 and a pre-chargeback communication network 360 for designatingtransaction disputes as either pre-chargebacks or chargebacks. FIG. 3illustrates the handling of chargebacks and/or pre-chargebacks. Networksystem 300 includes a cardholder 302, an issuer 304, a payment processor306, a merchant bank 308, a merchant 310, an issuer portal 314, DAcomputing device 316, and a merchant portal 318. According to an exampleembodiment, rather than initiate a chargeback using the proceduredescribed with respect to FIG. 2, a cardholder 302 is able tocommunicate with merchant 310 using DA computing device 316, asdescribed in FIG. 3. A network 340 is part of a chargeback system thatmay be similar to the chargeback system 200 described with respect toFIG. 2. Network 360 is a pre-chargeback network that may be used toresolve transaction disputes designated as pre-chargebacks. Network 340and network 360 are two separate communication networks that areconfigured to run independently of one another.

Cardholder 302 accesses issuer portal 314 to review a cardholder paymenttransaction history associated with a payment card. The transactionhistory includes one or more transactions made using the payment card.Cardholder 302 selects a transaction to dispute and transmits thedispute through issuer portal 314. Cardholder 302 may select a disputebutton or a pre-chargeback button displayed on the user interface ofissuer portal 314. Cardholder 302 may, for example, dispute thetransaction because he or she is unsatisfied with the goods or servicesprovided by merchant 310, may not recognize the purchase, and/or maydetermine the purchase is fraudulent.

Issuer portal 314 receives the dispute, including cardholder disputedata. This dispute data also includes transaction data associated withthe transaction being disputed. Issuer portal 314 transmits acorresponding dispute message, containing both the cardholder disputedata and associated transaction data, to the DA computing device 316.

In one embodiment, DA computing device 316 analyzes the dispute messageas described above to determine whether to transmit the dispute messageto payment processor 306 as a chargeback message or to merchant portal318 as a pre-chargeback message. In another embodiment, cardholder 302is given an option in issuer portal 314 whether to transmit the disputedata to payment processor 306 as a chargeback message or to merchantportal 318 as a pre-chargeback message. In still another embodiment,issuer 304 determines whether to enable cardholder 302 to transmit thedispute data to payment processor 306 as a chargeback message or tomerchant portal 318 as a pre-chargeback message.

If a pre-chargeback message is sent from DA computing device 316 tomerchant portal 318, merchant 310 can use merchant portal 318 to viewthe pre-chargeback message. Merchant portal 318 displays at least onepre-chargeback message, including at least some of the dispute data,enabling merchant 310 to review new pre-chargeback message and updatesto existing pre-chargebacks. Merchant 310 then reviews pre-chargebackmessage information and can provide a pre-chargeback response message.The response may include, for example, the merchant's intention toresolve the pre-chargeback and may include, for example, querying thecardholder for additional detail and/or providing store credit with themerchant to the cardholder.

The merchant's pre-chargeback response message may be sent to cardholder302 through merchant portal 318 by transmitting the pre-chargebackresponse message through pre-chargeback network 360 to DA computingdevice 316. DA computing device 316 transmits the response message toissuer portal 314. In some embodiments, cardholder 302 is notified ofthe response message as described above.

Cardholder 302 can respond, via a messaging section in issuer portal314, to the merchant's pre-chargeback response message usingpre-chargeback network 360. The cardholder may agree to a resolutionproposed by the merchant in the pre-chargeback response message.Alternatively, cardholder 302 and merchant 310 can continue to exchangemessages using the above-described process.

FIG. 4 is a data flow diagram 400 illustrating the flow of data betweencomponents of pre-chargeback network 360 described with respect to FIG.3. FIG. 4 depicts the data flow between cardholder 402 and merchant 410.In the example embodiment, cardholder 402 and merchant 410 are the sameor similar to cardholder 302 and merchant 310 respectively. The methodfurther includes issuer portal 414, DA computing device 416, paymentprocessor 406, merchant portal 418, and merchant 410. Issuer portal 414receives cardholder dispute data 422 from cardholder 402, which mayinclude one or more reasons for the transaction dispute, a narrativeregarding the disputed transaction, chosen multiple choice options, etc.The issuer portal collects cardholder dispute data 422 with associatedtransaction data 424 to generate dispute message 420. Associatedtransaction data 424 includes, but is not limited to, a primary accountnumber (PAN) associated with the payment card associated with thetransaction, account profile data for the PAN, a merchant identifier(ID), an acquiring bank identifier, an issuing bank identifier, anoriginal transaction amount, a transaction date and time, a merchantlocation ID, a card product type, a merchant category code, anauthorization code, and/or other transaction identifiers that may beused to identify the merchant and/or the disputed transaction. Thedispute message is transmitted by the issuer server to the DA computingdevice.

DA computing device 416 receives dispute message 420 from issuer portal414. In an example embodiment, DA computing device extracts disputemessage data 432 from dispute message 420 and stores it in database 430.Dispute message data 432 may include keywords or indicators from disputemessage 420. Database 430 also includes historical pre-chargeback data434 which may include indicators historically associated withtransactions that have been resolved using the pre-chargeback system.Database 430 also includes dispute designation model 440, constructedusing dispute message factors 442 and historical pre-chargeback data434. Dispute message factors 442 may be determined using naturallanguage processing, and/or statistical methods, and/or other machinelearning methods applied to historical pre-chargeback data 434. In someembodiments, the dispute designation model 440 and dispute messagefactors 442 are determined by the issuer. DA computing device 416 maycontain one or more dispute designation models 440 and one or more setof dispute message factors 442. In some embodiments, the DA computingdevice 416 associates each issuer portal 414 to at least one disputedesignation model 440 and at least one set of dispute message factors442.

In one embodiment, DA computing device 416 applies dispute designationmodel 440 to dispute message data 432 to designate the transactiondispute associated with dispute message 420 as either a chargeback or apre-chargeback. If the dispute is designated a chargeback, DA computingdevice 416 submits a chargeback message 436 to payment processor 406 toinitiate the chargeback process described with respect to FIG. 2. If thedispute is designated a pre-chargeback. DA computing device 416transmits the pre-chargeback message 426 to merchant portal 418 asdescribed with respect to FIG. 3. The contents of dispute message 420are contained, in whole or in part, within pre-chargeback message 426submitted to merchant portal 418. In another embodiment (not shown), thecardholder determines whether to (i) transmit the cardholder disputedata 422 through DA computing device 416 to the payment processor 406 asa chargeback message, or (ii) transmit the cardholder dispute data 422through DA computing device 416 to the merchant portal 418 as apre-chargeback message. In such an embodiment, DA computing device 416does not analyze cardholder dispute data 422. In still anotherembodiment (not shown), the issuer determines whether to (i) transmitthe cardholder dispute data 422 through DA computing device 416 to thepayment processor 406 as a chargeback message, or (ii) transmit thecardholder dispute data 422 through DA computing device 416 as apre-chargeback message.

Upon receiving dispute message 420 and determining it is to be routedthrough the pre-chargeback network as a pre-chargeback message, DAcomputing device 416 transmits the pre-chargeback message 426 to amerchant server. In one embodiment, DA computing device 416 isconfigured to use dispute message 420, particularly associatedtransaction data 424, to determine the merchant 410 associated with thepre-chargeback. In some embodiments, each merchant 410 has a separatemerchant portal 418. In such embodiments, DA computing device 416determines the particular merchant server that provides the merchantportal 418 for the identified merchant 410. DA computing device 416transmits the pre-chargeback message 426 to that merchant server. In analternative embodiment, all merchants 410 share a merchant portal 418but each merchant 410 has a separate messaging section to display,receive, and transmit message communications. In such embodiments, DAcomputing device 416 transmits pre-chargeback message 426 to a centralmerchant server that provides a merchant portal 418.

Merchant portal 418 displays at least one pre-chargeback message 426,including at least some of cardholder dispute data 422, enablingmerchant 410 to review new pre-chargebacks and updates to existingpre-chargebacks. Merchant portal 418 can be a website/webpage, a seriesof websites/webpages, a web application, or a mobile application.Merchant portal 418 further includes one or more messaging sections todisplay one or more text message communications, electronic mail (i.e.,emails), and/or other information relating to one or morepre-chargebacks. Merchant 410 then reviews pre-chargeback messages 426and can provide a pre-chargeback response message 450. Pre-chargebackresponse message 450 can include, for example, associated response data452 and a response indicator 454. Response indicator 454 may communicatethat merchant 410 intends to resolve the pre-chargeback using thepre-chargeback system. Response indicator 454 may further communicatethat a full or partial credit associated with the disputed transactionis being processed, provide store credit with merchant 410. Associatedresponse data 452 may include one or more queries to cardholder 402 foradditional detail.

Pre-chargeback response message 450 is transmitted by merchant portal418 to DA computing device 416 where it is received by a pre-chargebackresponse handler 435. In one embodiment, pre-chargeback response handler435 is configured to use data within pre-chargeback response message 450to determine the issuer portal 414 to receive pre-chargeback responsemessage 450. In some embodiments, cardholder 402 is notified ofpre-chargeback response message 450 as described above.

Cardholder 402 can respond (not shown), via a messaging section inissuer portal 414, to pre-chargeback response message 450. In someembodiments, the cardholder's response can be transmitted throughpre-chargeback response handler 435 to merchant portal 418. Cardholder402 and merchant 410 can continue to exchange messages using theabove-described process.

FIG. 5 illustrates an example configuration 500 of a DA computing deviceas shown in FIG. 4. DA computing device 516 includes a processor 504 forexecuting instructions. Instructions may be stored in a memory area 506,for example. Processor 504 may include one or more processing units(e.g., in a multi-core configuration).

Processor 504 is operatively coupled to a communication interface 508such that DA computing device 516 is capable of communicating with aremote device such as a merchant portal, an issuing portal, or a paymentprocessor. For example, communication interface 508 may transmitpre-chargeback data to the merchant portal and/or another client devicevia a network.

Processor 504 may also be operatively coupled to a storage device 510.Storage device 510 is any computer-operated hardware suitable forstoring and/or retrieving data. In some embodiments, storage device 510is integrated in DA computing device 516. For example, DA computingdevice 516 may include one or more hard disk drives as storage device510. In other embodiments, storage device 510 is external to DAcomputing device 516 and may be accessed by a plurality of servercomputer devices. For example, storage device 510 may include multiplestorage units such as hard disks or solid state disks in a redundantarray of inexpensive disks (RAID) configuration. Storage device 510 mayinclude a storage area network (SAN) and/or a network attached storage(NAS) system.

In some embodiments, processor 504 is operatively coupled to storagedevice 510 via a storage interface 512. Storage interface 512 is anycomponent capable of providing processor 504 with access to storagedevice 510. Storage interface 512 may include, for example, an AdvancedTechnology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, aSmall Computer System Interface (SCSI) adapter, a RAID controller, a SANadapter, a network adapter, and/or any component providing processor 504with access to storage device 510.

Memory area 506 may include, but are not limited to, random accessmemory (RAM) such as dynamic RAM (DRAM) or static RAM (SRAM), read-onlymemory (ROM), erasable programmable read-only memory (EPROM),electrically erasable programmable read-only memory (EEPROM), andnon-volatile RAM (NVRAM). The above memory types are exemplary only, andare thus not limiting as to the types of memory usable for storage of acomputer program.

FIG. 6 is a flowchart of a method 600 for designating a transactiondispute as a pre-chargeback for transmission over a pre-chargebacknetwork, such as network 360 (shown in FIG. 3). In the exampleembodiment, method 600 is performed by a DA computing device, such as DAcomputing device 316 (shown in FIG. 3). In certain embodiments, method600 may at least be partially performed by a different computing device.In other embodiments, method 600 may include additional, fewer, oralternative actions, including those described herein.

In 602, the DA computing device receives a transaction dispute,including transaction dispute data, from an issuer portal. The disputedata may include, for example, a transaction amount, a merchantidentification (ID), and a location of the merchant. In one embodiment,the DA computing device analyses 604 the dispute data as described aboveto designate 606 the transaction dispute as a chargeback or apre-chargeback. The DA computing device transmits 608 pre-chargebacks toa merchant portal and transmits 610 chargebacks to a payment processor.

As will be appreciated based on the foregoing specification, theabove-described examples of the disclosure may be implemented usingcomputer programming or engineering techniques including computersoftware, firmware, hardware or any combination or subset thereof. Anysuch resulting program, having computer-readable code means, may beembodied or provided within one or more computer-readable media, therebymaking a computer program product, i.e., an article of manufacture,according to the discussed examples of the disclosure. Thecomputer-readable media may be, for example, but is not limited to, afixed (hard) drive, diskette, optical disk, magnetic tape, semiconductormemory such as read-only memory (ROM), and/or any transmitting/receivingmedium such as the Internet or other communication network or link. Thearticle of manufacture containing the computer code may be made and/orused by executing the code directly from one medium, by copying the codefrom one medium to another medium, or by transmitting the code over anetwork.

The computer programs (also known as programs, software, softwareapplications, “apps”, or code) include machine instructions for aprogrammable processor, and can be implemented in a high-levelprocedural and/or object-oriented programming language, and/or inassembly/machine language. As used herein, the terms “machine-readablemedium” “computer-readable medium” refers to any computer programproduct, apparatus and/or device (e.g., magnetic discs, optical disks,memory, Programmable Logic Devices (PLDs)) used to provide machineinstructions and/or data to a programmable processor, including amachine-readable medium that receives machine instructions as amachine-readable signal. The “machine-readable medium” and“computer-readable medium,” however, do not include transitory signals.The term “machine-readable signal” refers to any signal used to providemachine instructions and/or data to a programmable processor.

For example, one or more computer-readable storage media may includecomputer-executable instructions embodied thereon for determining theprobability of an authorized transaction resulting in a chargeback. Inthis example, the computing device may include a memory device and aprocessor in communication with the memory device, and when executed bysaid processor the computer-executable instructions may cause theprocessor to perform a method such as the method described andillustrated in the example of FIG. 5.

The term processor, as used herein, refers to central processing units,microprocessors, microcontrollers, reduced instruction set circuits(RISC), application specific integrated circuits (ASIC), logic circuits,and any other circuit or processor capable of executing the functionsdescribed herein.

This written description uses examples to describe embodiments of thedisclosure, including the best mode, and also to enable any personskilled in the art to practice the disclosure, including making andusing any devices or systems and performing any incorporated methods.The patentable scope of the disclosure is defined by the claims, and mayinclude other examples that occur to those skilled in the art. Suchother examples are intended to be within the scope of the claims if theyhave structural elements that do not differ from the literal language ofthe claims, or if they include equivalent structural elements withinsubstantial differences from the literal language of the claims.

What is claimed is:
 1. A pre-chargeback computer network for processingpre-chargeback dispute messages, said network comprising: a disputeanalyzer (DA) computing device in communication with a memory; an issuerportal; and a first communication link connecting the issuer portal tothe DA computing device, wherein the DA computing device is configuredto: receive a dispute message identifying a disputed transaction fromthe issuer portal over the first communication link, the dispute messageincluding transaction data associated with the disputed transaction anddispute data; analyze the transaction data and the dispute data; androute the dispute message over the pre-chargeback computer network or aseparate chargeback network based on the analysis.
 2. The pre-chargebackcomputer network of claim 1 further comprising: a merchant portal; and asecond communication link connecting the merchant portal to the DAcomputing device, wherein the DA computing device is further configuredto: determine that the disputed transaction qualifies as apre-chargeback dispute based on the analysis; and route the disputemessage as a pre-chargeback dispute message to the merchant portal overthe second communication link.
 3. The pre-chargeback computer network ofclaim 2, wherein the DA computing device is further configured to:analyze the dispute data to determine a merchant involved in thedisputed transaction to receive the pre-chargeback dispute message; androute the pre-chargeback dispute message to the merchant portalassociated with the merchant.
 4. The pre-chargeback computer network ofclaim 2, wherein the merchant portal is configured to display one ormore pre-chargeback dispute messages associated with pre-chargebackdisputes and accept text entered by the merchant in response to the oneor more pre-chargeback dispute messages.
 5. The pre-chargeback computernetwork of claim 2, wherein the DA computing device is furtherconfigured to: receive a pre-chargeback response message over the secondcommunication link from the merchant portal, wherein the pre-chargebackresponse message was prepared by the merchant; and route thepre-chargeback response message over the first communication link to theissuer portal, wherein the pre-chargeback response message is accessibleby a cardholder.
 6. The pre-chargeback computer network of claim 1further comprising: a payment processor; and a third communication linkconnecting the DA computing device to the payment processor, wherein theDA computing device is further configured to: determine that thedisputed transaction qualifies as a chargeback dispute based on theanalysis; and route the dispute message as a chargeback dispute messageto the payment processor over the third communication link.
 7. Thepre-chargeback computer network of claim 1, wherein the dispute dataincludes at least one of (i) a narrative prepared by a cardholderrelating to the disputed transaction or (ii) one or more multiple choiceoptions selected by the cardholder relating to the disputed transaction.8. The pre-chargeback computer network of claim 1, wherein the DAcomputing device is further configured to determine whether the disputedtransaction is a chargeback or a pre-chargeback using at least one ofnatural language processing, statistical analysis, and machine learninganalysis.
 9. A computer-implemented method for processing pre-chargebackdispute messages over a pre-chargeback network, said method implementedusing a dispute analyzer (DA) computing device, said method comprising:receiving, by the DA computing device, a dispute message identifying adisputed transaction from an issuer portal over a first communicationlink, the dispute message including transaction data associated with thedisputed transaction and dispute data; analyzing, by the DA computingdevice, the transaction data and the dispute data; and routing, by theDA computing device, the dispute message over the pre-chargeback networkor a separate chargeback network based on the analysis.
 10. Thecomputer-implemented method of claim 9 further comprising: determining,by the DA computing device, that the disputed transaction qualifies as apre-chargeback dispute based on the analysis; and routing, by the DAcomputing device, the dispute message as a pre-chargeback disputemessage to a merchant portal over a second communication link.
 11. Thecomputer-implemented method of claim 10 further comprising: analyzing,by the DA computing device, the dispute data to determine a merchantinvolved in the disputed transaction to receive the pre-chargebackdispute message; and routing, by the DA computing device, thepre-chargeback dispute message to the merchant portal associated withthe merchant.
 12. The computer-implemented method of claim 10 furthercomprising: receiving, by the DA computing device, a pre-chargebackresponse message over the second communication link, wherein thepre-chargeback response message was prepared by a merchant involved inthe disputed transaction; and routing, by the DA computing device, thepre-chargeback response message over the first communication link to theissuer portal, wherein the pre-chargeback response message is accessibleby a cardholder.
 13. The computer-implemented method of claim 9 furthercomprising: determining, by the DA computing device, that the disputedtransaction qualifies as a chargeback dispute based on the analysis; androuting, by the DA computing device, the dispute message as a chargebackdispute message to a payment processor over a third communication link.14. The computer-implemented method of claim 9 further comprisingdesignating, by the DA computing device, the disputed transaction as achargeback or a pre-chargeback using at least one of natural languageprocessing, statistical methods, and machine learning analysis methods.15. A non-transitory computer-readable medium that includescomputer-executable instructions for processing pre-chargeback disputemessages over a pre-chargeback network, wherein when executed by adispute analyzer (DA) computing device comprising at least one processorin communication with at least one memory device, thecomputer-executable instructions cause the DA computing device to:receive a dispute message identifying a disputed transaction from anissuer portal over a first communication link, the dispute messageincluding transaction data associated with the disputed transaction anddispute data; analyze the transaction data and the dispute data; androute the dispute message over the pre-chargeback network or a separatechargeback network based on the analysis.
 16. The non-transitorycomputer readable medium of claim 15, wherein the computer-executableinstructions further cause the DA computing device to: determine thatthe disputed transaction qualifies as a pre-chargeback dispute based onthe analysis; and route the dispute message as a pre-chargeback disputemessage to a merchant portal over a second communication link.
 17. Thenon-transitory computer readable medium of claim 16, wherein thecomputer-executable instructions further cause the DA computing deviceto: analyze the dispute data to determine a merchant involved in thedisputed transaction to receive the pre-chargeback dispute message; androute the pre-chargeback dispute message to the merchant portalassociated with the merchant.
 18. The non-transitory computer readablemedium of claim 16, wherein the computer-executable instructions furthercause the DA computing device to: receive a pre-chargeback responsemessage over the second communication link, wherein the pre-chargebackresponse message was prepared by the merchant; and route thepre-chargeback response message over the first communication link to theissuer portal, wherein the pre-chargeback response message is accessibleby a cardholder.
 19. The non-transitory computer readable medium ofclaim 15, wherein the computer-executable instructions further cause theDA computing device to: determine that the disputed transactionqualifies as a chargeback dispute based on the analysis; and route thedispute message as a chargeback dispute message to a payment processorover a third communication link.
 20. The non-transitory computerreadable medium of claim 15, wherein the computer-executableinstructions further cause the DA computing device to determine whetherthe disputed transaction is a chargeback or a pre-chargeback using atleast one of natural language processing, statistical analysis, andmachine learning analysis.